Method and apparatus for blind checksum and correction for network transmissions

ABSTRACT

Method and apparatus for providing a checksum in a network transmission. In one aspect of the invention, a checksum for a packet to be transmitted on a network is determined by retrieving packet information from a storage device, the packet information to be included in the packet to be transmitted. A blind checksum value is determined based on the retrieved packet information, and the blind checksum value is adjusted to a protocol checksum based on descriptor information describing the structure of the packet. The protocol checksum is inserted in the packet before the packet is transmitted.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to the following copending U.S.patent applications:

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050059US1/3485P), entitled “Host Ethernet Adapter for NetworkingOffload in Server Environment”, filed on even date herewith and assignedto the assignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050060US 1/3486P), entitled “Method and System for AccommodatingSeveral Ethernet Ports and a Wrap Transmitted Flow Handled by aSimplified Frame-By-Frame Upper Structure”, filed on even date herewithand assigned to the assignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050061US1/3487P), entitled “Method and Apparatus for Providing aNetwork Connection Table”, filed on even date herewith and assigned tothe assignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050062US1/3488P), entitled “Network Communications for OperatingSystem Partitions”, filed on even date herewith and assigned to theassignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050073US1/3502P), entitled “Configurable Ports for a Host EthernetAdapter”, filed on even date herewith and assigned to the assignee ofthe present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050074US1/3503P, entitled “System and Method for Parsing,Filtering, and Computing the Checksum in a Host Ethernet Adapter (HEA)”,filed on even date herewith and assigned to the assignee of the presentinvention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050075US 1/3504P), entitled “System and Method for a Method forReducing Latency in a Host Ethernet Adapter (HEA)”, filed on even dateherewith and assigned to the assignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050082US 1/3512P), entitled “Method and System for Performing aPacket Header Lookup”, filed on even date herewith and assigned to theassignee of the present invention.

U.S. patent application, Ser. No. ______ (Attorney Docket No.RPS920050089US1/3516P), entitled “System and Method for Computing aBlind Checksum in a Host Ethernet Adapter (HEA)”, filed on even dateherewith and assigned to the assignee of the present invention.

FIELD OF THE INVENTION

The present invention relates to network transmissions for computerdevices, and more particularly to error detection using checksums innetwork transmissions.

BACKGROUND OF THE INVENTION

Computer systems communicate over networks by establishing and usingnetwork connections. When providing secure network connections, oneconcern is that data may be lost during network transmission, andvarious techniques are used to ensure that data is not lost in transit.An additional concern is the risk that errors will be introduced in datafrom transmission over the network. One technique for detecting networktransmission errors in data uses what is known as a checksum. The basictechnique of a checksum is to take a string of data bytes (or other unitof storage) and add them together, then send this sum with the datastream and have the receiver check the sum using the same method used tocreate the sum. If the receiver's calculated sum matches the sum in thedata stream, then no errors have been introduced during transmission.

For example, the Transmission Control Protocol (TCP) provides basicprotection against errors in transmission by including a 16-bit Checksumfield in the header of each data packet. In TCP, a standard algorithm isused to calculate the checksum which is slightly different than aconventional checksum algorithm. Instead of computing the checksum overonly the actual data fields of the TCP segment, a 12-byte TCP pseudoheader is created prior to checksum calculation. This header includesinformation taken from fields in both the TCP header and the IP datagraminto which the TCP segment will be encapsulated. The TCP pseudo headerincludes a source Internet Protocol (IP) address of the originator(taken from the IP header), destination IP address of the intendedrecipient (taken from the IP header), a reserved field, a protocol fieldfor specifying the protocol used, and a TCP length field specifying thelength of the TCP segment including header and data (body) (which iscalculated by the originator). The formed pseudo header is placed in abuffer, followed by the TCP segment, and the checksum is computed overthis set of data (pseudo header plus TCP segment). The value of thechecksum is placed into the Checksum field of the TCP header, and thepseudo header is discarded, since it is not an actual part of the packetand is not transmitted.

The packet is transmitted over the network, and the receiver performsthe same calculation by forming the pseudo header performing thechecksum (ignoring the Checksum value in the header field to replicatethe original condition). If there is a mismatch between its calculationand the value in the Checksum field, this indicates that an error ofsome sort occurred, and the packet can then be discarded or the errornoted. The checksum thus protects against errors in the TCP segmentfields and against incorrect segment delivery (if there is a mismatch inthe Source or Destination Address), incorrect protocol, and incorrectsegment length.

TCP checksum generation is often performed in hardware to achieve fasterperformance. Since the TCP checksum field is in the packet header, whichis transmitted before the packet data, true “on-the-fly” checksumgeneration is not provided. The packet data must be stored intransmission data buffers, and once the entire packet is received, thechecksum can be generated and placed in the header, and then the packetcan then start to be transmitted.

One problem with this packet transmission method is that it requiresrandom access to the data buffers storing the packet, so that thechecksum field can be accessed and written to with the determinedchecksum value. This random access capability to a large output bufferadds expense to the system and is slow and sequential, adding latency tothe system. Furthermore, the determination of the checksum value can addprocessing time to the transmission process, since the checksum value isdetermined only after the packet is fully stored in the data buffer.

In addition, portions of the packets to be transmitted are often storedin different configurations. For example, the header of a packet mightbe stored in an area of memory easily retrieved with a descriptor, butthe body of the packet may be stored elsewhere in memory. Or the headermay be stored with the body. However, there are no existing methods toefficiently combine parts of a packet and handle the different packetstorage configurations for checksum determination when transmitting.

Accordingly, what is needed is an apparatus and method for providing anetwork transmission mechanism that can efficiently process checksumsfor outgoing packets with minimal access to storage buffers,much-reduced latency, and efficient handling of packet storageconfigurations. The present invention addresses such a need.

SUMMARY OF THE INVENTION

The invention of the present application relates to providing a checksumin a network transmission. In one aspect of the invention, a method fordetermining a checksum for a packet to be transmitted on a networkincludes retrieving packet information from a storage device, the packetinformation to be included in the packet to be transmitted. A blindchecksum value is determined based on the retrieved packet information,the blind checksum value is adjusted to a protocol checksum based ondescriptor information describing the structure of the packet. Theprotocol checksum is inserted in the packet before the packet istransmitted.

In another aspect of the invention, an apparatus for determining achecksum for a packet to be transmitted on a network includes a memoryaccess unit that retrieves packet information from a storage device, thepacket information to be included in the packet to be transmitted. Anaccumulator determines a blind checksum value based on the retrievedpacket information, and a transmission unit adjusts the blind checksumvalue to a protocol checksum based on descriptor information describingthe structure of the packet. The transmission unit inserts the protocolchecksum in the packet and outputs the packet for transmission on thenetwork.

The present invention provides a method and apparatus that allowsefficient checksum determination and transmission of packets having achecksum by determining a blind checksum, if necessary, and adjustingthat blind checksum on-the-fly and without random accesses to databuffers. The invention allows low-latency checksum determination andpacket transmission and flexibility in handling multiple packetinformation storage configurations.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of an example of a system suitable for usewith the present invention;

FIGS. 2 a, 2 b, and 2 c are block diagrams illustrating different packettransmission systems that process packets and outputs them on aconnection line to a network;

FIG. 3 is a block diagram illustrating a packet transmission system ofthe present invention which can handle the different situationsillustrated in FIGS. 2 a-2 c;

FIG. 4 is a flow diagram illustrating a method of the present inventionfor providing a checksum for a packet to be transmitted over a network;and

FIGS. 5 a and 5 b are flow diagrams illustrating a method of the presentinvention for adjusting and determining a checksum value.

DETAILED DESCRIPTION

The present invention relates to network transmissions for computerdevices, and more particularly to error detection using checksums innetwork transmissions. The following description is presented to enableone of ordinary skill in the art to make and use the invention and isprovided in the context of a patent application and its requirements.Various modifications to the preferred embodiment and the genericprinciples and features described herein will be readily apparent tothose skilled in the art. Thus, the present invention is not intended tobe limited to the embodiment shown but is to be accorded the widestscope consistent with the principles and features described herein.

The present invention is mainly described in terms of systems providedin particular implementations. However, one of ordinary skill in the artwill readily recognize that this method and system will operateeffectively in other implementations. For example, the systemarchitectures and network configurations usable with the presentinvention can take a number of different forms. The present inventionwill also be described in the context of particular methods havingcertain steps. However, the method and system operate effectively forother methods having different and/or additional steps not inconsistentwith the present invention.

To more particularly describe the features of the present invention,please refer to FIGS. 1 through 5 b in conjunction with the discussionbelow. The present invention is described in the context of a TCP/IPprotocol network system; however, other protocols (such as User DatagramProtocol (UDP), etc.) and configurations can be used in otherembodiments.

FIG. 1 is a block diagram of a system 10 suitable for use with thepresent invention. System 10 is a computer system such as a server,mainframe, desktop client computer, workstation, or other computer orelectronic device. System 10 can communicate with various other computersystems 12 over a network 14. System 10 can run one or more applications16, which are processes running on the system. For example, anapplication 16 can provide data that is to be sent out over the networkto one or more computer systems 12.

System 10 includes one or more TCP/IP stacks 20 to manage networkcommunications to and from the system 10. The stack 20 is process codein an operating system or user software space running on the serverwhich handles the incoming and outgoing data to and from the networkconnections 14. The TCP/IP stack can establish a new network connectionto a server application 16, provide packets to an existing connection,etc. Each application 16 may have one or more connections. For example,the stack 20 (and/or other components) can provide data from application16 as TCP/IP network packets to destination ports and addresses over thenetwork 14. The stack 20 also receives network packets provided by othercomputer devices 12 on the network and provides the packets to theapplication 16 via network connections. The TCP/IP stack 20 can accessmain storage 22 of the system 10 to store packets intended to be sentout on the network 14. Storage 22 can be any suitable type of memoryprovided on a computer system, as is well known.

One or more device drivers 18 is running on the system 10 and caninterface with the main memory 22 as well as the network adapter 24. Thedevice driver 18 can, for example, write a packet descriptor into themain storage 22 with some parameters given by the TCP/IP stack 20 oreven by an application 16. The packet descriptor (“descriptor”) includescharacteristics for a packet to be transmitted and instructions as towhat actions to take for the packet, which may be stored elsewhere inmain storage 22, such as in buffers, and a pointer or address of whereportions of the packet is stored in main storage 22, if applicable.

A network adapter 24 is used to provide the physical connection pointbetween the system 10 and other computer systems 12 connected to thenetwork 14. Adapter 24 can be, for example, a hardware network interfaceadapter. The adapter can take packets provided in main storage 22 andprocess them for transmission on the network, and send out the packets,as well as receive packets from the network 14. For example, in thepresent invention, the adapter 14 includes processing components so thatthe adapter can determine a TCP checksum that is added to each TCP/IPdata packet before it is output on the network 14. This is detailedbelow with respect to FIGS. 2 a-c and FIG. 3.

A checksum value is added to the header of each TCP packet using aparticular method so that a receiver of the packet can use the samechecksum method to generate its own checksum value and compare with thechecksum value in the packet to determine if the packet has anytransmission errors. A “packet”, as referenced herein, is an entireTCP/IP packet, including an Ethernet header (including a Media AccessControl (MAC) address), followed by an Internet Protocol (IP) header,followed by a TCP header, and followed by a body (data). The TCP segmentis the TCP header and the body. The terms apply analogously to otherprotocols used in other embodiments, such as UDP.

A packet for transmission may be split such that different parts of thepacket are stored in different areas of main memory 22 by the stack 20.Three examples that show how a packet intended for transmission may bedistributed in main storage 22, and that show different systems for anadapter 20 for processing those packet distributions, are describedbelow with reference to FIGS. 2 a, 2 b, and 2 c.

FIG. 2 a is a block diagram illustrating a packet transmission system 50including main storage 22 and a hardware adapter 52 that processespackets and outputs them on a connection line 56. In the example of FIG.2 a, a descriptor 58 has been written into the main storage 22 by adevice driver or other program running on the system 10 which governsthe sending out of a packet (e.g., with some parameters given by theTCP/IP stack 20 or even by an application 16). The descriptor 58includes instructions as to what actions to take for an associatedpacket stored elsewhere in main storage 22, and a pointer or address ofwhere the body of the packet is stored in main storage 22.

Header 60 is the header for the packet associated with the descriptor58. The header includes the standard TCP and IP header information, aswell as other header information such as Ethernet MAC address, ifapplicable. The header was placed in the main buffer main storage by theTCP/IP stack 20, while the Ethernet header, if present, was placed by anEthernet device driver. Body 62 is stored in the buffer in the samepartition of main storage 22 as the header 60 and is the data for thepacket associated with the descriptor 58. Body 62 was placed in mainstorage by an application 16 running on the system or was copied thereby the TCP/IP stack 20.

When transmitting the packet, a Tx processor 64 on the adapter 52retrieves the descriptor 58 from an area of main storage 22 (a“descriptor area” which is the area where the descriptor is stored). TheTx processor 64 then instructs a Direct Memory Access (DMA) unit 66 toretrieve the packet header 60 and body 62 from the buffer of mainstorage 22 at an address indicated by the retrieved descriptor 58. TheDMA unit 66 provides the retrieved packet header and body to the databuffers 68 of the adapter 52. Tx processor 64 retrieves the header andbody from data buffers 68 using random access, e.g., one byte at a time,and determines a checksum. The checksum is calculated by creating a TCPpseudo header that includes parts of the IP header within the header 60(a source IP address, destination IP address, and protocol), and a TCPsegment length (calculated by processor 64 or received as information inthe descriptor 58). The checksum is calculated based on the TCP segmentand pseudo header. The Tx processor then writes the checksum value backto the data buffers 70 in the TCP checksum field of the header 60. Theheader and body are then output from the data buffers 70 on the networkconnection line 56 to a destination on the network.

FIG. 2 b is a block diagram illustrating a packet transmission system100 including main storage 22 and a hardware adapter 104 that processespackets and outputs them on a connection line 106. In the example ofFIG. 2 b, a descriptor 108 has been written into a descriptor area ofmain storage 22 by a device driver or other program running on thesystem 10. Similar to the example of FIG. 2 a, the descriptor 108includes instructions as to what actions to take for an associatedpacket stored elsewhere in main storage 22, and a pointer or address ofwhere the body of the packet is stored in main storage 22.

In this example, the header 110 of the packet associated with thedescriptor 108 is stored in same descriptor area and block of mainstorage 22 as the descriptor 108. For example, the header 110 candirectly follow the descriptor 108 in memory. This storage scheme mayhave occurred to due particular circumstances and efficiencies in thesystem 10. For example, the protocol stack 20 and device driver maycoordinate to store the descriptor and header in the same block of mainstorage, for efficiency. Or, there may be advantages for keepingapplication data (the body) separate from the header, e.g., in the casethat the application wishes to eliminate the copy of data by the TCP/IPstack between application buffers and operating system kernel buffers(a.k.a. a “zero-copy”). The body 112 of the packet is stored in thebuffer of main storage 22 at some location and memory block differentthan descriptor 108 and header 110.

When transmitting the packet, a Tx processor 114 on the adapter 104retrieves the descriptor 108 and header 110 from main storage 22. The Txprocessor 114 then instructs a DMA unit 116 to retrieve the packet body112 from main storage 22 at an address indicated by the descriptor 108.The DMA unit 116 provides the body 112 to the data buffers 118 of theadapter 104. The Tx processor 114 retrieves the body 112 from the databuffers 118 using random access, e.g., one byte at a time, anddetermines a checksum. As in the example of FIG. 2 a, the checksum iscalculated over the TCP segment of the packet and a created pseudoheader. The Tx processor stores the checksum value in the header 110 andthe header 110 is sent to a merge block 120 from Tx processor 114. Thedata buffers 118 are instructed to send the body 112 to merge block 120after the header 100, so that the body is merged with the header and thefull packet is output on connection line 106. This system 100 requiresless access and writing to the data buffers 118 than the system 50 ofFIG. 2 a and thus can be more efficient (and merge unit is typicallymore efficient than writing to data buffers 118).

FIG. 2 c is a block diagram illustrating a packet transmission system150 including main storage 22 and a hardware adapter 154 that processesdata packets and outputs them on a connection line 156. In this system,the descriptor 158, the associated packet header 160, and the associatedpacket body 162 are stored in the descriptor area of main storage 102,e.g., contiguously. This storage configuration is made possible if thebody 162 is small enough in size so that it does not need to be storedand processed using larger data buffers 168. When transmitted thepacket, the descriptor 158, header 160, and body 162 are retrieved bythe Tx processor 164 of the adapter 154, which has all the informationit needs to calculate a checksum as explained above, add the checksum tothe appropriate field of the header 160, and output the header 160 andbody 162 as a packet on connection line 156. This example and system donot require use of a DMA unit 166 or data buffers 168 on the adapter154, and do not require address translation to read the packetinformation from the buffer of main storage 22, and thus is the mostefficient of the examples of FIGS. 2 a-2 c.

FIG. 3 is a block diagram illustrating a packet transmission system 200of the present invention. Advantages of system 200 include its abilityto handle any of the three cases illustrated in FIGS. 2 a-c, and itperforms on-the-fly checksum accumulation and checksum adjustment, andthus faster, more efficient packet transmission. Furthermore, itrequires no random access to the data buffers and thus no additionallogic and latency for that function.

System 200 includes main storage 22 and a network hardware adapter 204,which includes components that process packets to be sent out and outputthe packets on a connection line 206 of the network.

Main storage 22 stores the parts of the packet that is to betransmitted. The possible storage locations for parts of the packet areall illustrated in FIG. 3, to indicate that all of these cases can behandled by system 200. Thus, a descriptor 208 is stored in main storage22, by a device driver or other program running on the system 10 whichis sending out a packet, in a descriptor area. In some cases, the header210 of the packet is stored in the same descriptor area and block ofmemory as the descriptor 208, as described above with reference to FIG.2 b. And in some cases, the body 212 (if it is small enough) is storedin the same descriptor area and block of memory with the descriptor 208and header 210, as described above with reference to FIG. 2 c (also, theIP header portion of the header 210 could be stored with the descriptor208 and the TCP header portion of header 210 stored with the body 212).In other cases, the header 210 and the body 212, or just the body 212,are stored in a buffer area of main storage 22 different than the areastoring descriptor 208, as described above with reference to FIGS. 2 aand 2 b.

The processing system 200 on adapter 204 includes a Tx processor 216that controls the packet transmission functions of the system 200. Txprocessor 216 retrieves descriptor 208 and other packet information (ifpresent) from main storage 22, and sends appropriate instructions anddata to the components of the system 200 to control their operation,including a DMA unit 218, data buffers 220, a merge unit 222, and an XCSunit 224. The term “packet information,” as used herein, refers to apacket header 210 and/or body 212.

DMA unit 218 retrieves the header 210 and body 212 of the packet, ifstored in a different area of main storage than the descriptor 208. Inthe present invention, an accumulator 219 has been added to the DMA unit218 to perform a blind checksum for received data on-the-fly (as it isbeing retrieved), and provides the blind checksum value to Tx processor216, which sends the blind checksum value to the XCS unit 224. The mergeunit 222 merges any packet information provided by the Tx processor(such as header 210 in some cases) with any packet information receivedfrom the data buffers 220. The data buffers 220 are large enough to holdthe maximum size of packet usable with the system 200 and computersystem 10.

Transmit Checksum (XCS) unit 224 of the present invention is providedafter merge unit 222 and receives the packet information merged by thatunit. The XCS unit performs an adjustment and correction of the blindchecksum value provided by the Tx processor 216 to create a standard TCPchecksum value. The XCS unit is given other information from the Txprocessor 216 to facilitate the adjustment process. The XCS unit canadjust the blind checksum as the packet header is received, and outputsthe packet on line 206 and out to the network 14 on-the-fly after theadjustment of the blind checksum is performed based on the header of thepacket.

It should be noted that embodiments of the system 200 of the presentinvention can perform multiple DMA actions by DMA unit 218. For example,there can be “gather” descriptors in descriptor 208, which are differentDMA instructions, each pointing to different areas of memory. This cancause several DMA operations to happen sequentially by the DMA unit 218.This can be appropriate, for example, in a case in which packetinformation for a packet, such as the body, is split across manydifferent non-contiguous areas of main storage 22; each DMA action canretrieve packet information from a different area of main storage.

In some embodiments, there can be multiple Tx processors 216 and DMAunits 218 working in parallel to speed the processing of packets.

FIG. 4 is a flow diagram illustrating a method 250 of the presentinvention for providing a checksum for a packet to be transmitted over anetwork. This process is implemented preferably by the network adapter24 in hardware.

The process begins at 252, and in step 254, a descriptor 208 isretrieved from the descriptor area of main storage 22 by the Txprocessor 216. Any packet information stored in the descriptor areawhich may be stored with the descriptor (in appropriate cases) is alsoretrieved, such as header 210, or header 210 and body 212, of thepacket. In step 256, the process checks whether there is packetinformation in the main buffer of main storage 22 to be loaded. In somecases, the entire body 212 and header 210 was loaded to the Tx processor216 with the descriptor 208 in step 254, and thus no packet informationneed be loaded from the main buffer. In some other cases, the body 212and/or the descriptor 210 are stored in the main buffer. In yet othercases, part of the body 212 is stored with the descriptor 208, and partof the body 212 is stored in the main buffer.

If no packet information need be loaded from the main buffer, then theprocess continues to step 258, in which the packet information and otherinformation needed to determine the TCP checksum (explained in greaterdetail with respect to step 270) is provided to the XCS unit 224 fromthe Tx processor 216. The packet information can be sent via the mergeunit 222, without any actual merging occurring, and the otherinformation can be directly provided to the XCS unit, or in otherembodiments the other information can be sent via the merge unit 222with the packet. In next step 260, the XCS unit calculates a TCPchecksum from the received information. The checksum is calculated usinga pseudo header based on the information in the IP header and from thedescriptor, and the checksum calculated based on the TCP segment andpseudo header. An example method for calculating the checksum isdescribed below with reference to FIGS. 5 a and 5 b. It should be notedthat in this case, the checksum is being created rather thanadjusted/corrected, since no blind checksum was previously determined.The process then continues to step 272, described below.

If the packet body was not retrieved with descriptor 208 as checked instep 256, then the process continues to step 262, in which the DMA unit218 is instructed by the Tx processor 216 to load the packet informationfrom the buffer of main storage 22 at an address indicated by address orpointer information in the retrieved descriptor 208, and a blindchecksum is calculated. In some cases, the header 210 and the body 212are retrieved as packet information from main storage 22 in this step,while in other cases, just the body 212 is retrieved.

The blind checksum of step 262 is calculated by an accumulator 219 whichcan be included in the DMA unit 218. It is a “blind” checksum in thesense that the accumulator does not follow established rules to create aTCP checksum, i.e., with a pseudo header; it instead accumulates a sumsimply based on the values of successive normally aligned halfwords(2-byte strings of bits) of packet information retrieved from the bufferof main storage 22 (storage units other than halfwords can be processedin other embodiments). All the halfwords transferred from main storage22 are included, from the start of the packet up to the end of the IPpayload, i.e., including Ethernet header, the IP header, the TCP header,and the body of the packet that are included as the payload of thesurrounding IP packet information. Not included are the Ethernet paddingbytes (if any) or the Ethernet Cyclical Redundancy Check (CRC), a.k.a. aFrame Check Sequence (FCS) 4-bytes at the end. If the packet informationstarts or ends on an odd boundary in memory, as indicated by theaddresses where it is stored, then the packet information is padded witha zero appropriately to allow the packet to properly align on an evenboundary.

In next step 264, the buffer packet information from main storage 22 isstored in the data buffers 220 (this actually can occur as each portionof the packet information is being retrieved by the DMA unit). Inaddition, once the packet information from main storage 22 is fullyretrieved, the accumulated blind checksum value is sent to the Txprocessor 216. In step 266, it is checked whether the header 210 waswith the body 212 in the packet information retrieved from the buffer ofmain storage 22 in step 262. In one case, the header 210 was retrievedwith the body 212 from the buffer area of main storage 22 and bothheader and body are stored in data buffers 220; if this is the case, theprocess continues to step 270, described below, where both header andbody are sent via the merge unit 222 to the XCS unit 224.

In the other case, the header 210 is not retrieved with the body 212,since the header 210 was retrieved by the Tx processor 216 in step 254with the descriptor 208 from the descriptor area of main storage 22. Ifthis is the case, then the process continues to step 268, in which theheader from the Tx processor 216 and the body from the data buffers 220is merged at the merge unit 222. For example, the Tx processor 216 sendsthe header 210 to the merge unit 222, and then instructs that the body212 in the data buffers 118 be sent to the merge block 222 to be placedafter the header 210 so that the header is merged with the body tocreate the full packet. The process then continues to step 270.

In step 270, the packet and other information is sent from or via themerge unit 222 to the XCS unit 224. The other information is directlysent from the Tx processor 216 to the XCS unit 224. In otherembodiments, the other information can be sent with the packet via themerge unit 222, e.g., prepended to the packet as a “sticker” which islater removed by the XCS unit; such an embodiment requires no directconnections of Tx processor and XCS unit. The other information includesthe blind checksum value and an immediate data length (IMMLEN) valuethat indicates the number of bytes of the packet which has not beenincluded in the blind checksum of step 262 (known from the descriptor208).

Depending on the parsing abilities of the XCS unit in differentembodiments, the other information may also include an IP start offsetindicating the offset in halfwords (or other storage unit) at which theIP header begins from the beginning of the packet, a TCP start offsetindicating the offset at which the TCP segment begins from the beginningof the packet, and a TCP checksum offset indicating the offset inhalfwords at which the TCP checksum field begins. For example, in thedescribed embodiment, the XCS unit 224 does not parse this offsetinformation from the packet, but instead receives it directly from theTx processor 216, where the Tx processor retrieved it from thedescriptor 208. In a different embodiment, the XCS unit 224 can parsethe packet to determine these offsets, e.g., start at the beginning ofthe packet at, e.g., Ethernet packet information, and continue field byfield to the IP header start, the TCP header start, the TCP checksumfield start, etc.

The XCS unit 224 can include a small buffer (e.g., 256 bytes) allowingrandom access to access the checksum field (which could end up atvirtually any location in the buffer due to various Ethernet, IP, andTCP header lengths and previous packet sizes which may still be in thebuffer). The buffer is used to store the packet (or a portion thereof)until the checksum is fully determined.

In next step 272, the XCS unit 224 adjusts the blind checksum value tocorrect this checksum so that it corresponds to a TCP checksum. The XCSunit determines whether to adjust the blind checksum value based onexamined halfwords in the packet. The XCS unit performs this function onthe fly, as each halfword is being received; thus, step 272 ispreferably integrated with step 274 as the packet information is beingreceived. A method that the XCS unit 224 can use to adjust the blindchecksum value, and achieve the TCP checksum, is described in greaterdetail below with respect to FIGS. 5 a and 5 b.

In next step 274, the XCS unit 224 places the determined TCP checksum inthe TCP header of the packet, using the TCP checksum field offsetreceived as other information in step 270 or 258, and sends the packetout on the line 206 out to the network 14. Once the XCS unit hasexamined enough halfwords to have fully adjusted the checksum, then theTCP checksum value is placed in the checksum field and the packet isbegun to be transmitted, and all remaining halfwords of the packetreceived at the XCS unit 224 can be output on line 206 on the fly, asthey are received; this is a significant advantage of the presentinvention. The process is then complete at 276. It should be noted thatthere is no need to discard a created pseudo header, because a pseudoheader is never separately created; rather, it is included in thedetermined checksum as part of the adjustment process. Anothersignificant advantage of the invention is that the random access neededis limited to only the small size of the buffer in the XCS unit (e.g.,256 bytes), instead of for the large size of the data buffers (e.g., 9kilobytes for a “jumbo” frame buffer). Random access capability is moreexpensive to set up for larger buffers. In addition, in the presentinvention, each byte of the packet does not have to be ready from a“distance” and the checksum need not be calculated after the packet isreceived; rather, the checksum is accumulated as the packet passes, bothin the accumulator 219 and in the XCS unit 224, which is much moreefficient.

FIGS. 5 a and 5 b are flow diagrams illustrating a method detailing aparticular implementation of step 272 of method 250 of FIG. 4, in whichthe XCS unit 224 adjusts the blind checksum value to achieve a TCPchecksum (or calculates the TCP checksum directly without using a blindchecksum, in some cases). The method of FIGS. 5 a and 5 b is just oneexample of how the final checksum determination can be implemented.

The process begins at 282 in FIG. 5 a, and in step 284, a halfwordpointer (HP) is moved to the next halfword (HW) in the received packetinformation. The first time step 284 is performed, the pointer starts atthe first halfword of the packet (offset zero). As detailed above forFIG. 4, the XCS unit 224 receives the blind checksum value from the Txprocessor 216, and the packet information that is to be transmitted viathe merge unit 222. As each halfword is received by the XCS unit, itmoves its halfword pointer to that received halfword, to achieveon-the-fly examination and adjustment of the blind checksum value. Asexplained above, this method assumes the XCS unit received otherinformation from the Tx processor 216, such as various offsets requiredin order to know the positions of various fields in the packet and tostore it in the TCP header. E.g., the XCS unit knows where the IP headerstarts due to having received an IP header offset, and knows where theTCP header starts by having received a TCP header offset. Alternatively,the XCS unit can determine or parse these offsets by moving the pointera known, standard number of bits or bytes through the packet informationfor each field and offset. Based on these offsets, the XCS can calculatethe offsets of other fields such as the IP SA and DA offsets, needed forthe checksum determination.

As described above, one of the other values received from the Txprocessor 216 is the IMMLEN value, which is the immediate data lengthfor the packet, i.e., the number of bytes in the packet that have notbeen included in the blind checksum, as known from the descriptor 108.Thus, if IMMLEN equals zero, this indicates that all of the packethalfwords were included in the blind checksum, and that if anyadjustment is required for the current halfword, it will be to subtractit from the blind checksum. Likewise, if IMMLEN is not zero (i.e.,positive), then some of the packet halfwords were not included in theblind checksum, and subtraction and/or addition of halfwords may beneeded for correction. In the described embodiment, it is assumed thatIMMLEN is either zero or greater than the IP packet start; thisrestriction reduces hardware implementation complexity. Otherembodiments can used methods to avoid this restriction.

In next step 286, the process checks whether the halfword pointer is atthe IP source address (SA) or the IP destination address (DA) stored inthe IP header of the packet. This information typically is specified infull words, so there are two halfwords provided for each address. If thepointer is at a halfword for one of these addresses, then the processchecks in step 288 whether IMMLEN is equal to zero. If so, then asindicated in step 290 the checksum is not adjusted, and the processreturns to step 284 to move to and examine the next halfword. If IMMLENis not equal to zero, then this IP address information was not includedin the blind checksum, and in step 292 the current halfword is added tothe blind checksum. This is because the IP source and destinationaddresses are required for TCP checksum determination, i.e., theseaddresses are included in the pseudo header used in TCP checksumdetermination. The process then returns to step 284.

If the check of step 286 is negative, then in step 294 the processchecks whether the halfword pointer is at a halfword describing theprotocol field and time-to-live (TTL) field of the IP header of thepacket. Each of these fields is a byte, and thus the halfword wouldinclude both fields. If the pointer is at this halfword, then in step296 the process checks whether IMMLEN is equal to zero (i.e., whetherthis halfword is already included in the blind checksum). If so, in step298 the TTL portion (byte) of the halfword is subtracted out, since theTTL field is not needed in the pseudo header to determine the TCPchecksum; this leaves the protocol field, which is needed in the pseudoheader. The process then returns to step 284 to move to and examine thenext halfword. If IMMLEN is not equal to zero, then this IP addressinformation was not included in the blind checksum, and in step 300 theprotocol portion of the halfword (byte) is added to the blind checksum,since the protocol field is needed in the pseudo header. The processthen returns to step 284.

If the check of step 294 is negative, then in step 302 the processchecks whether the halfword pointer is at a halfword describing theVersion field (half byte), IP Header Length (HL) field (half byte), andType of Service (TOS) field (1 byte) of the IP header of the packet. Ifthe pointer is at this halfword, then in step 304 the process checkswhether IMMLEN is equal to zero. If so, in step 306 this halfword issubtracted from the blind checksum, since these fields are not needed inthe TCP pseudo header. In addition, the IP Header Length field is savedin a hardware latch (or other convenient storage), since this field isneeded for step 314 (described below). The process then returns to step284. If IMMLEN is not equal to zero, then the current halfword was notincluded in the blind checksum, and in step 308 the IP Header Lengthfield is subtracted from the blind checksum. This is in anticipation ofstep 316 (described below), in which the total length is added; sincethe required pseudo header length field is the TCP segment length (IPtotal length minus IP header length), the IP Header Length can besubtracted out now. The process then returns to step 284. Note that thisis an advantage of the present invention: a normally unused adder cyclein which the XCS unit would do nothing, is instead efficiently utilizedto make an adjustment to the blind checksum in anticipation of otheradjustments, thus saving additional operations at the time of thoselater adjustments and avoiding the use of additional halfword adders.

If the check of step 302 is negative, then in step 310 the processchecks whether the halfword pointer is at a halfword describing the IPTotal Length field of the packet in the IP header of the packet. If thepointer is at this halfword, then in step 312 the process checks whetherIMMLEN is equal to zero and this halfword is included in the blindchecksum. If so, in step 314 the IP Header Length field saved in a latchin step 306 is subtracted from the blind checksum, since the pseudoheader needs the TCP segment length (i.e., IP total length minus IPheader length) to determine the TCP checksum. The process then returnsto step 284. If IMMLEN is not equal to zero, then the current halfwordwas not included in the blind checksum, and in step 316 the currenthalfword is added to the blind checksum. This creates the desired TCPsegment length in the pseudo header since the IP Header Length issubtracted in step 308. The process then returns to step 284.

If the check of step 310 is negative, then in step 318 the processchecks whether the halfword pointer is less than or equal to the IPheader end, i.e. whether the pointer is at a halfword in the IP headerthat is not covered by the steps described above. If the pointer is atsuch a halfword location in the packet, then in step 320 the processchecks whether IMMLEN is equal to zero and this halfword is included inthe blind checksum. If so, in step 322 the current halfword issubtracted from the blind checksum value, since the pseudo header or TCPchecksum does not need any other IP header halfwords or fields exceptthose described in the steps above. The process then returns to step284. If IMMLEN is not equal to zero, then the current halfword was notincluded in the blind checksum, and as indicated in step 324, thechecksum is not adjusted. The process then returns to step 284.

If the check of step 318 is negative, then the process continues to step326, as detailed in FIG. 5 b. The remaining steps include situationswhere the halfword pointer is pointed to halfwords in the TCP header,the TCP payload, and after the TCP payload.

In step 326, the process checks whether the halfword pointer is equal tothe TCP checksum field. If so, in step 328, the process checks whetherthe halfword pointer is equal to IMMLEN, i.e., whether the currenthalfword has an offset equal to the number of bytes not included in theblind checksum. If so, then it indicates that the halfword pointer is atthe halfword at a boundary, and that the checksum field is at thatboundary. In step 330 the process checks whether IMMLEM is on aneven-numbered address boundary. If so, a halfword is subtracted out instep 332, and the process returns to step 284. If on an odd boundary,then only the lower byte of the halfword is subtracted out in step 334,since the upper byte is already included in the blind checksum. Theprocess then returns to step 284. If the pointer is not equal to IMMLENat step 328, then in step 336 the process checks whether the pointer isgreater than IMMLEN. If so, a halfword is subtracted out in step 338,and the process returns to step 284. If not, the checksum is notadjusted as indicated in step 340, and the process returns to step 284.

In step 326, the process checks whether the halfword pointer is equal toIMMLEN, i.e., whether the current halfword has an offset equal to thenumber of bytes not included in the blind checksum. If so, then itindicates that the halfword pointer is at the halfword at a boundary,such as the boundary between the IP header and the TCP header, or theboundary at the end of the packet; the location of the boundary dependson how much of the packet was included in the blind checksum. In step328 the process checks whether IMMLEM is on an odd-numbered addressboundary. If so, then in step 330 only the upper byte of the currenthalfword is added to the blind checksum value, since the lower bytebelongs to the TCP header, for example, and was already included in theblind checksum value. The blind checksum value has thus been fullyadjusted to conform to a TCP checksum, and the process is then completeat 338. If the pointer is at an even numbered boundary, then noadditional bytes need be added, and the blind checksum value is notcorrected as indicated in step 332 (e.g., a zero can be added). Theadjustment/correction process of the blind checksum is then over asindicated at 338, resulting in a TCP checksum value.

If the check of step 326 is negative, then the process continues to step334, in which the process checks whether the halfword pointer is greaterthan IMMLEN, i.e., whether the current halfword is at a halfword alreadyincluded in the blind checksum or is after the end of the TCP payload.If so, then remaining halfwords are already included in the blindchecksum value, and the checksum is not adjusted as indicated in step336. The adjustment process of the blind checksum to a TCP checksumvalue is then over as indicated at 338. If the halfword pointer is notgreater than IMMLEN at step 334, then it is less than IMMLEN andpointing to a halfword that was not included in the blind checksum.Thus, in step 340, the current halfword is added to the blind checksum,and the process then returns to step 284 for the next halfword. Forexample, step 340 can add halfwords to the checksum from the TCP headeror body which were not included in the blind checksum (or if a blindchecksum was never created, e.g., the body 212 was provided directly toTx processor 216).

It should be noted that the process of FIGS. 5 a and 5 b assumes thatthe header 210 is not stored so that it is split between the descriptorarea of main storage 22 and the buffer area of main storage, i.e., thatthe header data remains contiguous. This is because this process assumesthat the IMMLEN value, retrieved from the descriptor 108, does not fallwithin the Ethernet or IP header, i.e., it is either zero or greaterthan the start offset of the IP header.

Although the present invention has been described in accordance with theembodiments shown, one of ordinary skill in the art will readilyrecognize that there could be variations to the embodiments and thosevariations would be within the spirit and scope of the presentinvention. Accordingly, many modifications may be made by one ofordinary skill in the art without departing from the spirit and scope ofthe appended claims.

1. A method for determining a checksum for a packet to be transmitted ona network, the method comprising: retrieving packet information from astorage device, the packet information to be included in the packet tobe transmitted; determining a blind checksum value based on theretrieved packet information; and adjusting the blind checksum value toa protocol checksum based on descriptor information describing thestructure of the packet, wherein the protocol checksum is inserted inthe packet before the packet is transmitted.
 2. The method of claim 1wherein the blind checksum value is determined by summing all theretrieved packet information.
 3. The method of claim 1 wherein adjustingthe blind checksum value includes adding or subtracting at least onehalfword value of the packet information to or from the blind checksumvalue.
 4. The method of claim 3 wherein the packet to be transmitted isa TCP/IP packet, and wherein adjusting the blind checksum value includesadding a halfword value to the blind checksum value if the halfwordvalue is an IP header field required to determine a TCP checksum valueand the halfword value was not included in the blind checksum.
 5. Themethod of claim 3 wherein the packet to be transmitted is a TCP/IPpacket, and wherein adjusting the blind checksum value includessubtracting a halfword value from the blind checksum value if thehalfword value is an IP header field not required to determine a TCPchecksum value and the halfword value was included in the blindchecksum.
 6. The method of claim 1 wherein the retrieved packetinformation includes a header and a body of the packet.
 7. The method ofclaim 1 wherein the retrieved packet information includes a body of thepacket and no header of the packet, and further comprising retrievingthe header of the packet with the descriptor information.
 8. The methodof claim 7 further comprising merging the header with the body of thepacket after the blind checksum is determined for the body.
 9. Themethod of claim 1 further comprising sending the packet information to adata buffer after the blind checksum has been determined, wherein thepacket information is retrieved from the data buffer for the adjustingof the blind checksum.
 10. The method of claim 1 further comprisingretrieving the descriptor information from the storage device.
 11. Themethod of claim 10 wherein the blind checksum value is determined whenat a portion of the packet information is stored separately from thedescriptor in memory, and further comprising: determining the protocolchecksum based on descriptor information describing the structure of thepacket, if the packet information is stored with and retrieved with thedescriptor information.
 12. The method of claim 1 further comprisingdetermining the descriptor information by parsing the packetinformation.
 13. The method of claim 1 wherein the packet is providedaccording to the TCP/IP protocol.
 14. The method of claim 3 whereinadjusting the blind checksum value includes subtracting out bytes of anIP header portion of the packet information and leaving in bytes of theIP header portion that are needed for a pseudo header to create a TCPchecksum.
 15. The method of claim 14 wherein adjusting the blindchecksum value includes subtracting out one byte of a halfword andkeeping the other byte of the halfword for fields in the IP headerportion in which only one byte of the field is needed in the pseudoheader.
 16. The method of claim 3 wherein adjusting the blind checksumvalue includes subtracting out one byte of a halfword and keeping theother byte of the halfword if the halfword is positioned on a boundarybetween a portion of the packet information already included in theblind checksum value and a portion not included in the blind checksumvalue.
 17. An apparatus for determining a checksum for a packet to betransmitted on a network, the apparatus comprising: a memory access unitthat retrieves packet information from a storage device, the packetinformation to be included in the packet to be transmitted; anaccumulator that determines a blind checksum value based on theretrieved packet information; and a transmission unit that receives thepacket information and the blind checksum value and adjusts the blindchecksum value to a protocol checksum based on descriptor informationdescribing the structure of the packet, wherein the transmission unitinserts the protocol checksum in the packet and outputs the packet fortransmission on the network.
 18. The apparatus of claim 17 wherein theaccumulator determines the blind checksum value by summing retrievedpacket information as it is loaded.
 19. The apparatus of claim 17further comprising a transmission processor, wherein the transmissionprocessor retrieves the descriptor information from the storage deviceand provides the descriptor information to the transmission unit. 20.The apparatus of claim 19 wherein the transmission processor receivesthe blind checksum value from the accumulator and provides the blindchecksum value to the transmission unit.
 21. The apparatus of claim 17further comprising a data buffer coupled to the memory access unit,wherein the data buffer receives the packet information from the memoryaccess unit, and wherein the packet information is sent from the databuffer to the transmission unit.
 22. The apparatus of claim 17 whereinthe retrieved packet information includes a header and a body of thepacket.
 23. The apparatus of claim 17 wherein the retrieved packetinformation includes a body of the packet and no header of the packet,and wherein the memory access unit retrieves the header of the packetwith the descriptor information.
 24. The apparatus of claim 23 furthercomprising a merge unit that merges the header with the body of thepacket after the accumulator determines the blind checksum for the bodyand wherein the transmission unit receives the merged packet informationfrom the merge unit.
 25. The apparatus of claim 17 wherein thetransmission unit adjusts the blind checksum value includes adding orsubtracting at least one halfword value of the packet information to orfrom the blind checksum value.
 26. The apparatus of claim 25 wherein thepacket to be transmitted is a TCP/IP packet, and wherein thetransmission unit adjusts the blind checksum value by adding a halfwordvalue to the blind checksum value if the halfword value is an IP headerfield required to determine a TCP checksum value and the halfword valuewas not included in the blind checksum.
 27. The apparatus of claim 25wherein the packet to be transmitted is a TCP/IP packet, and wherein thetransmission unit adjusts the blind checksum value by subtracting ahalfword value from the blind checksum value if the halfword value is anIP header field not required to determine a TCP checksum value and thehalfword value was included in the blind checksum.
 28. The apparatus ofclaim 19 wherein the transmission processor also retrieves the packetinformation with the descriptor information from storage device andprovides the packet information to the transmission unit, wherein thetransmission unit creates the protocol checksum based on the descriptorinformation.